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ABSTRACT 


An evaluation of the performance of a SONET management system was con¬ 
ducted to better understand its management capabilities due to network disruptions in the 
presence of a traffic load. This study analyzed the Cisco Transport Manager (CTM) 
which manages a testbed of four Cisco ONS15454 optical systems. The network was in¬ 
jected with HTTP and FTP traffic generated by the Spirent Smartbits system installed 
with TeraMetrics Gigabit Ethernet modules and load calibration configured by the 
Spirent Avalanche software. To simulate real-world situations, power disruptions were 
applied to the network while collecting CTM traffic using Ethereal. Using queuing analy¬ 
sis, the arrival rates and service times were computed for various CTM traffic compo¬ 
nents and a utilization for 2500 network elements (NE) extrapolated. Self-similarity 
analysis was perfonned and the log-variance was plotted to extract the Hurst values. Fi¬ 
nally, the results and findings were compared with prior research for loading and no¬ 
loading cases. The results of this study are useful in detennining the maximum number of 
network elements manageable in a disruptive environment. Final analysis on the effects 
of link utilization on the queue size showed that the CTM is able to manage more NEs 
when the network is disrupted. Unfortunately, managing more NEs increases the queue 
size even though the utilization was found to be 0.83 for 5450 NEs. Consequently, in or¬ 
der to maintain a moderate queue size, the maximum number of NEs manageable was 
found to be 2495. This value is close to CISCO’S specification of a CTM server manag¬ 
ing a maximum of 2500 NEs. 
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EXECUTIVE SUMMARY 


In today’s network-centric warfare, the success of point-to-point communications 
hinges upon the survivability of the operations network. As networks grow and more ser¬ 
vices are introduced, managing the entire network becomes a daunting task. Deploying a 
super network management system or a manager of managers may be a solution but 
without the necessary tools to analyze and predict performances, it could result in pre¬ 
cious time and revenue wasted as these advanced network management tools are very ex¬ 
pensive. 

This study investigated the perfonnance of the Cisco Transport Manager (CTM 
version 4.6) in managing a Synchronous Optical Network (SONET) operating under ex¬ 
ternal factors of network loading and power disruptions. Using empirical statistical meth¬ 
ods, the effect of power disruptions on the SONET management traffic is analyzed. As 
SONET systems are configured in a ring topology, traffic could be routed by another path 
when one of the optical systems is down. 

The CTM was deployed in an IP network and configured to manage four units of 
Cisco optical transport systems, known as ONS15454, which are installed in the Ad¬ 
vanced Network Laboratory of the Naval Postgraduate School. 

The optical systems are managed via its 192-kbps Section Data Communication 
Channel (SDCC) which is provisioned in the fiber links. Although Cisco has specified 
that the CTM is able to manage a maximum of 2500 NEs, the performance may differ 
under different network conditions. Prior studies, [11] and [12], have shown that the 
maximum numbers of NEs manageable are 1027 for a no-traffic loading network, and 
1552 for a fully loaded network. The latter result is interesting as it was expected that the 
number of NEs manageable should drop due to higher intensity of network traffic. 

The load traffic of this thesis was generated by the Spirent Smartbits 6000 hard¬ 
ware data generator which generates HTTP and FTP packets configured using Spirent 
Smartbits Avalanche software. The duration of the traffic was configured to run for ten 
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days. The CTM management traffic was collected using an open source packet sniffer 
called Ethereal which collects the data packets arriving and leaving the CTM server. In 
particular, the management traffic of interest were Socks, SNMPv2 and related TCP data 
packets which are collectively referred to as CTM Ethernet traffic. 

The analysis was performed using statistical methods by modeling the interarrival 
times and packet sizes as random variables based on the CTM data traffic collected. 
Queuing theory was applied to compute the arrival rates and service times which enable 
the utilization to be derived and subsequently extrapolated to estimate the utilization of 
2500 NEs. Self-similarity analysis was also performed to extract the Hurst values of the 
CTM traffic. Finally, the maximum number of NEs was deduced using the Norros model 
which defines the relationship between utilization and queue size. 

From the traffic analysis, it was observed that the Socks and SNMPv2 traffic de¬ 
creases when the SONET network is loaded and disrupted by NE power failures. Though 
lower, the total Ethernet traffic was about 20% higher compared to the case when the net¬ 
work was loaded but not disrupted. While the decrease in Socks and SNMPv2 was due to 
the NE offline, the increase in Ethernet traffic was deduced to be generated by the CTM 
server due to polling of the NEs. 

Further analysis on the interarrival time statistics revealed that the means are 
higher compared to no-disruption case. The higher mean interarrival times suggests that 
the arrival rate is lower which is consistent with the fact that the distribution graphs ex¬ 
hibit a faster decay rate compared to the no-disruption case. The statistical analysis on the 
packet size statistics revealed that the distribution varies only slightly when compared to 
the no-disruption case. Despite the minute differences, the Ethernet packet mean packet 
size was lower due to averaging over more packets collected for the loading/disruption 
case. Interestingly enough, Socks and SNMPv2 packet size means were lower too, al¬ 
though the number of packets were lower compared to the loading case. 

The self-similarity analysis revealed that Socks traffic for the loading/disruption 
case was less self-similar compared to loading case, while more self-similar compared to 
no-loading case. The SNMPv2 traffic Hurst value drops below 0.5 which indicated that it 
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does not possess an exponential distribution due to disruption. The combined Socks and 
SNMPv2 had a Hurst value which fell in between the loading and no-loading cases, sug¬ 
gesting the dominant effect of Socks traffic over SNMPv within the SDCC channel. Nev¬ 
ertheless, the CTM Ethernet traffic was less self-similar compared to both loading and no 
loading cases. 

Final analysis on the effects of link utilization on the queue size showed that the 
CTM is able to manage more NEs when the network is disrupted. Unfortunately, manag¬ 
ing more NEs increases the queue size even though the utilization was found to be 0.83 
for 5450 NEs. Consequently, in order to maintain a queue size of 1, for a utilization of 
0.38, the maximum number of NEs manageable was found to be 2495. This value is close 
to CISCO’S specification of CTM server managing a maximum of 2500 NEs. 

Study of network loading coupled with power disruptions is an important research 
area which will be useful for high-speed computer networks administrators. The results 
and findings of this thesis will benefit the SONET network administrators by increasing 
their awareness of the limitations of SONET network management systems. Further, this 
research provides the ability to optimize the deployment of SONET optical systems in 
order to tackle network problems associated with network loading and power disruptions. 
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I. INTRODUCTION 


A. MOTIVATION 

Systems adhering to the SONET/SDH standards have been widely deployed as 
the fiber optics transport backbone of many telecommunications service providers’ net¬ 
works. SONET was first introduced by Bellcore (now Tecordia) in the mid 1980’s as the 
optical transport technology to support high capacity transport and has become the de- 
facto standard in the industry [1], SONET is a very reliable transport system and until this 
date no suitable technology is able to replace it. The next generation SONET is built on 
Wavelength-Division Multiplexing (WDM) technology which provides much higher ca¬ 
pacity [2]. This has occurred in tandem with the emerging field of Traffic Engineering 
(TE) which has become an important research area in optimizing and protecting next- 
generation optical networks [3]. 

SONET stands for Synchronous Optical Network which is defined by the Ameri¬ 
can National Standards Institute (ANSI) for synchronous digital networks using optical 
media in the North America [4]. Its international equivalent is Synchronous Digital Hier¬ 
archy (SDH) which is the European standard defined by the ITU. In a typical deployment 
of the SONET system, a dedicated control channel known as the Section Data Communi¬ 
cations Channel (SDCC) is provisioned as part of overhead in all the fiber links. This en¬ 
ables the SONET management system to communicate with the network elements which 
are deployed geographically apart. 

In real-world situations, disruptions or network outages due to power failures and 
fiber disconnections are often unavoidable. Although there has been research on the 
measurement and modeling of computer networks with self-similar nature - specifically 
in the areas of router and web traffic [5], Internet traffic [6], wireless traffic [7], and 
Ethernet traffic [8] - the effects of network loading coupled with power disruptions have 
not been fully investigated. Furthermore, highly self-similar traffic could cause queuing 
delays, increase packet drop rates and prolonged periods of congestion [9]. As such, net¬ 
work loading coupled with power disruptions is an important research area useful for 
high-speed computer networks administrators. 
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Although SONET has the advantage of re-routing traffic via the next available op¬ 
tical path, it is not kn own whether the utilization rate of SDCC channel would be in¬ 
creased. Furthermore, it is known that current SONET management systems in the mar¬ 
ket employ several management protocols to manage their network elements [10], and 
these different types of management traffic behave differently within the network. It is 
important to understand whether disruption would affect the number of network elements 
manageable or cause bottlenecks within the network, due to an increase in management 
traffic. More importantly, it is imperative to investigate whether the management server 
is able to handle the possible increase in management traffic due to network disruptions. 

Very often, the SONET network is designed based on the vendors’ specification 
of the maximum number of network elements manageable. Over years of operation, net¬ 
work sizes expand and more nodes are added. Even though the total number of network 
elements is kept well within the maximum stated by the vendor, we do not know to what 
extent introducing more nodes would affect the utilization of the SDCC link. Further¬ 
more, we do not know how disruptions within the network would affect the SDCC and 
whether it would cause the SDCC link utilization to increase or decrease. 

B. THESIS OBJECTIVE 

Armed with these questions in mind, it is important to investigate the perfonnance 
of the SONET management system, to analyze the effects of disruptions using statistical 
means, and to derive the optimal number of network elements manageable with real- 
world factors taken into consideration. This is an important research area as the results 
and findings of this study would be useful and valuable, not only to the industry as well 
as the military in deploying SONET systems, but also to facilitate the understanding of 
the underlying intricacies of the network management paradigm in the fast-paced IT 
world. 

For the purpose of this study, a Cisco SONET system was used as a platfonn to 
study the perfonnance and effectiveness of a network management tool in managing the 
optical systems. Under this study, the network elements are the Cisco ONS15454 optical 
transport systems while the element management system is the Cisco Transport Manager 
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(version 4.6). The CTM’s server management performance was investigated by simulat¬ 
ing network disruption within the fiber network under the conditions of injected data traf¬ 
fic within the network. Data analysis was performed on the data packets collected at the 
CTM server and statistical analysis was perfonned to determine the number of manage¬ 
able NEs under loading of network with simulated disruption. 


C. PRIOR WORK 

In recent research by Lim [11], traffic analysis was carried out on the manage¬ 
ment traffic between the CTM server and ONS15454 without loading or disruption. It 
was found that the number of manageable NEs was 1027. A later study by Ng [12] car¬ 
ried out on the same network, with actual traffic loading of the fiber network, detennined 
that the number of manageable NEs to be 1552. 


D. THESIS ORGANIZATION 

This chapter has presented the motivation of this study and the thesis objectives. 
Prior related work was also discussed. The next chapter introduces the Cisco SONET sys¬ 
tem overview and the network management system. Chapter III discusses the laboratory 
setup of the equipment for the data collection of the CTM management traffic. Chapter 
IV presents the statistical techniques employed in the analysis of the data collected. 
Chapter V discusses the results and findings from the statistical analysis. Last but not 
least, Chapter VI summarizes the research work with proposals for future work. 
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II. SONET NETWORK MANAGEMENT SYSTEM OVERVIEW 

A. CHAPTER OVERVIEW 

This chapter presents the Cisco ONS15454 system overview, discussing the fea¬ 
tures of the ONS 15454 optical system as a multiservice transport platform. The network 
management tools of Cisco Transport Client (CTC), Cisco Transport Manager Client and 
Server are also described. In addition, a brief discussion on the Simple Network Man¬ 
agement Protocol (SNMP) is presented. 


B. INTRODUCTION 

As optical networks become very large, an efficient network management system 
is needed to manage resources. Telecommunications network management is an impor¬ 
tant area in the telecommunication industry as operators are concerned with revenue, ser¬ 
vice assurance, maintaining Service Level Agreements (SLA), and keeping operations 
costs low. Understanding the market concern, CISCO has introduced the CISCO Trans¬ 
port Manager (CTM), the industry’s most advanced optical network management system 
[13]. In compliance with the Telecommunications Management Network (TMN) frame¬ 
work [14], the CTM sits within the Network Management Layer (NML) and the Element 
Management Layer (EML). Essentially, it is a Network Element (NE) manager, which 
incorporates industry standard interfaces for managing the optical devices, and provides 
management functions, operations, provisioning and maintenance of the entire optical 
network. 

C. CISCO ONS15454 SYSTEM OVERVIEW 

The Cisco ONS 15454 is a SONET optical network system which provides a mul¬ 
tiservice provisioning platform. It supports Time Division Multiplex standards for inter¬ 
faces such as DS-1, DS-3, and EC-1, and data interfaces for Ethernet and Gigabit 
Ethernet [13], The optical transport interface supports OC-3 to OC-192 with integrated 
dense WDM (DWDM). 
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Within the Advanced Network Laboratory of Naval Postgraduate School, four 
ONS15454 optical systems are installed in a ring configuration simulating the locations 
of Pacific Grove, Carmel, Salinas and Monterey, as depicted in Figure 1. Note that the 
dotted circle represents the SDCC link which supports the transfer of the management in¬ 
formation. The Monterey optical system is connected to the IP network where the Cisco 
Transport Controller (CTC) Client, the Cisco Transport Manager (CTM) server and the 
CTM Client are located. The CTC Client is installed and configured to run on a Windows 
2003 server. The CTM Client is installed on a Windows XP machine while the CTM 
Server is installed on Solaris server. Both the CTM Client and Server used in this labora¬ 
tory setup are version 4.6. The following sections describe the respective software in de¬ 
tail. 


PACIFIC GROVE MONTEREY 



Figure 1. CISCO ONS 15454 and SONET Network Management System 

Setup (After Ref. [11].) 


1. Cisco Transport Client (CTC) 

The Cisco Transport Client (CTC) is a Windows web-based Java program in¬ 
stalled on a Windows 2003 server [15]. It is used to monitor the health status and alarms 
of the ONS 15454 nodes. It also provides provisioning capabilities for configuration of 
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the ONS15454 expansion cards to provision the fiber li nk s and the Ethernet connections 
as depicted in Figure 2. It communicates with the CTM Server continuously to monitor 
the health status and to update the network provisioning configurations. 



Figure 2. CTC management interface 

2. Cisco Transport Manager Client (CTM Client) 

The CTM Client is a Windows Java-based program installed on a Windows XP 
machine [15]. It is used to communicate with the CTM server for all activities related to 
user access and administration, network configuration and management services configu¬ 
ration. Figure 3 shows the CTM Client management interface for the Carmel optical sys¬ 
tem. The figure shows that Slot 3, 7 and 8 of the optical system are provisioned for 
Ethernet interface, OC12 circuit and two control channels, respectively. 
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Figure 3. CTM Client management interface 


3. Cisco Transport Manager Server (CTM Server) 

The CTM server is the Element Management System (EMS) for the ONS15454 
fiber network [15]. It manages all fiber optic network elements and stores the configura¬ 
tions within its Oracle 8i database system which is installed on the same Solaris machine 
as the CTM. The CTM server issues commands and downloads configuration and per¬ 
formance information from every ONS 15454 connected to the network. 

4. The Section Data Communications Channel (SDCC) 

The SDCC forms the heart of the SONET/SDH management transport functions. 
Essentially, the SDCC is a dedicated 192-kbps channel which is included in the 
SONET/SDH overhead and conveys the management information between the optical 
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systems and the network management system [3]. The SDCC conveys all management 
traffic which are Socks and SNMPv2. The SDCC link is illustrated as the dotted line 
within the SONET ring in Figure 1. 

D. SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) 

SNMP is a distributed network management protocol used to manage network 
elements which are connected within an IP network. Currently, there are three versions 
defined by the IETF [16]. The first version, SNMPvl, supports server commands “Get,” 
“GetNext” and “Set,” and agent commands “Get-Response” and “Trap.” SNMPvl is in¬ 
efficient as it retrieves the management information “entry-by-entry” and is thus time 
consuming and bandwidth inefficient. The second version, SNMPv2, implements two 
additional commands, “GetBulk” and “Inform”, as well as enhances the protocol opera¬ 
tions. The “GetBulk” command is used to efficiently retrieve the entire record of man¬ 
agement information from the network elements. Lastly, SNMPv3 adds security and al¬ 
lows remote configuration capabilities in addition to the previous versions. 

Currently, the CTM server supports SNMPv2 for managing the ONS15454 opti¬ 
cal switches which are connected within the IP network. 

E. SUMMARY 

In this chapter, the Cisco SONET optical transport system overview has been pre¬ 
sented. A brief introduction of the SNMP protocol was also discussed. The next chapter 
describes the laboratory setup and the configuration details of Cisco SONET system. 
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III. LABORATORY SETUP AND PROCEDURES 


A. CHAPTER OVERVIEW 

This chapter presents the laboratory setup of the Cisco SONET system describing 
the configurations of the Cisco ONS15454 optical system and the Cisco Transport Man¬ 
ager. The procedures for configuring the Spirent SmartBits 6000 traffic generator and for 
load calibration of the Spirent Avalanche software are also explained. The process of ap¬ 
plying disruptions to the SONET network is described. Finally, the CTM data traffic col¬ 
lection procedure is presented. 


B. DEFINING THE TEST SCENARIO 

The objective of this study was to investigate the performance of the SONET 
management system under loading with network disruption. In order to simulate real 
world conditions, the SONET network was loaded with HTTP and FTP traffic to simulate 
users accessing web servers and establishing FTP sessions for data transfer. For disrup¬ 
tions within the network, one or more ONS 15454 optical systems were switched off and 
turned back on a couple of times each day. This manual switching process was repeated 
over a 10-day data collection period. The entire process would be sufficient to simulate 
network loading with network outages manually induced on a worst case basis. 

C. CONFIGURATION OF LABORATORY EQUIPMENT 

The following describes the configurations of the respective laboratory compo¬ 
nents, the traffic generation and data collection processes. 

1. Laboratory Setup of Equipment 

The ONS 15454 optical systems and CTM management system were installed and 
set up by Lim [11]. The ONS 15454 nodes are connected in a ring with one of the 
switches connected to the IP network, as shown in Figure 4. Each ONS 15454 is installed 
with a ML 1000 card which provides Gigabit Ethernet connection to the LAN. Only one 
IP connection is necessary as the ONS 15454 optical systems are interconnected by the 
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SDCC channel which is provisioned in the fiber li nk s. The SDCC channel acts as the 
control channel and bridges to the IP network so that the CTM server can communicate 
with the optical systems via this channel. Another reason that the network was set up in 
this manner was to simulate the different geographical locations at which these optical 
switches are installed. 

CTC CLIENT CTM CLIENT CTM SERVER 


VMndows 2003 server VMndowsXP Solaris 

192.168.200.7 192.168.200.11 192.168.200.10 



Figure 4. Laboratory Setup of the Cisco SONET system and 
Spirent traffic generator (After Ref. [12].) 


The SmartBits 6000 chassis developed by Spirent Communications was con¬ 
nected to the IP network. It was installed with two TeraMetrics Gigabit Ethernet modules 
which provide the optical interfaces for connection to the ML 1000 Gigabit interface cards 
on the ONS15454 chassis. 
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2. Configuring the ML1000 Interfaces 

The ML 1000 interface card supports Gigabit Ethernet access to allow bridging the 
LAN network to the optical transport network. Each ONS15454 was installed with this 
card which was connected to the TeraMetrics Gigabit Ethernet interfaces on the Spirent 
SmartBits 6000 chassis for data traffic to be injected into the SONET network. The IP 
addresses of the POS and Gigabit Ethernet interfaces of every ONS 15454 card were con¬ 
figured by Ng [12] based on the configurations depicted in Table 1. 


ONS15454 

Card 

Gigabit Ethernet 
Interface 

POSO 

POS1 

Salinas 

192.168.90.183 

192.168.1.153 

192.168.2.163 

Monterey 

192.168.100.183 

192.168.1.163 

192.168.2.163 

Pacific Grove 

192.168.110.183 

192.168.1.173 

192.168.2.173 

Cannel 

192.168.120.183 

192.168.1.183 

192.168.2.183 

Table 1. IP addresses of the O' 

NS 15454 Packet-Over-SONET and 


Gigabit Ethernet interfaces (From Ref. [12].) 


3. Configuring the Spirent Smartbits Traffic Generator 

In order to inject real traffic into the optical network, a hardware and software 
setup using the Spirent Communications systems were required as shown in Figure 5. 

The Spirent SmartBits 6000 chassis was installed with two TeraMetrics LAN-3321 A Gi¬ 
gabit Ethernet interface cards [17]. The SmartBits 6000 chassis and the TeraMetrics cards 
were configured using the SmartBits Avalanche software via the IP connection as shown 
in Figure 4. 


4. Configuring the SmartBits 6000 Chassis 

The TeraMetrics modules were configured with the settings shown in Table 2. 
Note that the TeraMetrics modules have to be configured in the same subnet with the Gi¬ 
gabit Ethernet interface cards of the ONS 15454 optical systems. 
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5. Load Calibration using the SmartBits Avalanche Software 

The SmartBits Avalanche software [18] was used to configure the following 

items: 

a. Number of servers and clients 

b. Types of servers (HTTP, FTP, SMTP, etc.) 

c. Length of data traffic injection 

Each TeraMetrics module features two fiber interface ports which are connected 
to the ML1000 cards on the ONS15454 chassis. One of the TeraMetrics fiber interface 
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ports is configured as a server-LAN while the other is a client-LAN. The second 
TeraMetrics interface card is configured in a similar manner. Table 2 shows the configu¬ 
ration of the TeraMetrics modules and the connection to which ONS15454 chassis. Fig¬ 
ure 6 shows the configuration of 100 clients and Figure 7 shows the association of the 
client-LANs with the respective TeraMetrics modules. 


TeraMetric Mod¬ 
ule IP address 

Design¬ 
ated as 

Types of 

servers/ 

clients 

IP addresses config¬ 
ured in Spirent Ava¬ 
lanche Software 

Connected to 

which 

ONS15454 

192.168.200.153:0 
Card 1, port 0 

Server- 

LAN 

HTTP 
and FTP 

servers 

192.168.100.1 (HTTP) 

192.168.100.2 (FTP) 

192.168.100.3 (HTTP) 

Monterey 

192.168.200.153:1 
Card 1, port 1 

Server- 

LAN 

HTTP 
and FTP 

servers 

192.168.110.1 (HTTP) 

192.168.110.2 (HTTP) 

192.168.110.3 (FTP) 

Pacific Grove 

192.168.200.154:0 
Card 2, port 0 

Client- 

LAN 

100 Cli¬ 
ents 

192.168.90.1-100 

100 Clients 

Salinas 

192.168.200.154:1 
Card 2, port 1 

Client- 

LAN 

100 Cli¬ 
ents 

192.168.120.1-100 

100 Clients 

Carmel 


Table 2. Configuration of the TeraMetrics modules the connections 



Figure 6. Snapshot of configuration of the client subnets 
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Figure 7. Snapshot of association of client-LANs with the TeraMetrics modules 

6. Load Calibration 

Once the TeraMetric modules were configured, the data traffic load calibration 
was configured using the model shown in Figure 8. Using the Spirent Avalanche soft¬ 
ware, four phases of the loading process were configured. Phase I is the ramping up of 
the data traffic to a height of X number of connections. Phase II is known as stepping 
whereby the number of connections is increased by steps of X from X to AX. Phase III is 
known as the sustaining stage whereby the maximum number of connections are held for 
a period of time. Finally at Phase IV, the ramp down process, the number of connections 
are brought to zero. 
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. Actual Load 

Figure 8. Diagram of the data traffic generation test phases (From Ref. [13].) 


Based on the requirement of 10-day data collection period, the settings in Table 3 
were configured in the “Load” submenu of the Spirent Avalanche software. 


Phases 

Settings 

Values 

Units 

Phase 1: Ramp up 

Time 

300 

Seconds 


Height 

50 

Connections 

Phase 2: Stepping 

Step ramp time 

300 

Seconds 


Step steady time 

215,625 

Seconds 


Step height 

50 

Connections 


Number of steps 

3 


Phase 3: Holding 

Holding time 

215,625 

Seconds 


Holding height 

200 


Phase 4: Ramp down 

Minimum finishing 
time 

300 

Seconds 

Total time 

300 + 300 x 3 + (215625) x 3 +215625 + 300 
= 864,000 seconds or 10 days 


Table 3. Load calibration settings of the Spirent Avalanche software 


7. Configuring the SONET Network Management System 

In order to ensure that the CTM management traffic is flowing through the SDCC 
link, the following additional steps have to be taken. 
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Using the CTC client, each ONS15454 was configured with SNMP destination 
address of 192.168.200.10 and port number 162 so that SNMP traps could be sent to the 
CTM server. Port 163 is used for CTM server communicating with ONS 15454. Figure 9 
shows a snapshot of the SNMP trap setting for Pacific Grove. The IP address of the CTM 
server is entered with the UDP port number set to 162. 

Next, the CTM Client is initiated to ensure that the management services and 
processes are configured. As depicted in the CTM Client “NEService” submenu window 
of Figure 10, the ONS 15454 “green arrow” is up signifying that the management services 
are running on the CTM server. This is the management information conveyed in the 
SDCC link. 



Figure 9. Snapshot SNMP traps settings in the CTC Client interface 
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Figure 10. Snapshot of management services and processes settings in the CTM 

Client interface 


Lastly, on the Solaris machine where the CTM server is running, the command 
“showctm” is executed to display the management processes which have been configured 
to run. Figure 11 shows the snapshot from the Solaris machine which displays the proc¬ 
esses of “SnmpTrapService,” “SMService,” and “NEService” running on the CTM 
server. 



Figure 11. Snapshot of CTM management processes 
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8. Configuring Ethereal 

After the SONET network and the Spirent traffic generator have been set up, the 
data packets of the CTM server are ready to be collected. An open source data packet 
sniffer kn own as Ethereal is installed on the Solaris server to collect the CTM manage¬ 
ment traffic. Figure 12 shows a snapshot of the Ethereal application running on the CTM 
server. It captures all incoming and outgoing packets at the CTM server and records the 
arrival times and packet lengths of all the packets. 



Figure 12. Snapshot of Ethereal application running on the Solaris machine 

9. Power Disruption Simulation 

The Ethereal application is executed to commence with the CTM data traffic col¬ 
lection process which is immediately followed by initiating the traffic generation from 
the Spirent Avalanche application. Figure 13 shows the routing of traffic from Carmel to 
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Pacific Grove when Salinas is down. During the 10-day period, the ONS15454 desig¬ 
nated as Salinas was switched off once a day for the first 5 days. Each time the 
ONS 15454 was switched on, the average network recovery time was about 7 minutes. 
For the remaining 5 days, both Salinas and Carmel were switched off 2-3 times each day. 


Traffic routing 


PACIFIC GROVE via this path MONTEREY 



192 . 168 . 200.210 192 . 168 . 200.213 


Figure 13. Power Disruption simulation of Salinas and traffic routing 


During the process, the times at which the specific ONS 15454 were switched off 
were recorded and the duration of the outage noted. Table 4 shows the complete log re¬ 
corded in this study. Fogging down the outage durations enables the network availability 
to be estimated. 

From Table 4, by taking into consideration that the optical system takes about 7 
minutes to synchronize the traffic flow, the network availability is estimated to be about 
97.16%. Thus the network outage is about 2.84%. 


21 











Date 

Time 

Optical system 
switched off 

Duration of power 
disruption (min) 

Jan 26 

1700 

Test Started 



1730 

1730 

1 

Jan 27 

0800 

Salinas 

1 

Jan 28 

1345 

Salinas 

1 

Jan 29 

0730 

Salinas 

1 

Jan 30 

0830 

Salinas 

1 

Jan 31 

0810 

Salinas, Carmel 

30 


1115 

Salinas, Carmel 

15 


1335 

Salinas, Carmel 

15 

Feb 1 

0820 

Salinas, Carmel 

30 


0920 

Salinas, Carmel 

20 


1105 

Salinas, Carmel 

30 


1715 

Salinas, Carmel 

30 

Feb 2 

0915 

Salinas, Carmel 

40 


1200 

Salinas, Carmel 

40 


1445 

Salinas, Carmel 

1 

Feb 3 

0915 

Salinas, Carmel 

1 


1105 

Salinas, Carmel 

1 


1405 

Salinas, Carmel 

1 

Feb 4 

0900 

Salinas, Carmel 

1 


1200 

Salinas, Carmel 

1 


1500 

Salinas, Carmel 

1 


Table 4 


Complete logging of optical system switched off over the 10-day period 


D. SUMMARY 

The laboratory setup and test procedures have been described in this chapter. The 
configurations and settings of the Cisco optical systems and network management sys¬ 
tems are detailed. The procedures for configuring the Spirent SmartBits 6000 chassis and 
Avalanche software are described. In the next chapter, the relevant probability theory and 
the self-similarity concept are presented. 
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IV. PROBABILITY THEORY AND SELF SIMILARITY 


A. CHAPTER OVERVIEW 

This chapter presents the probabilistic theory of exponential and Poisson distribu¬ 
tion which are important in the analysis of data traffic. Some basic queuing theory equa¬ 
tions are also discussed which are fundamental to the analysis of the data packets. Lastly, 
the self-similarity concept is presented. 


B. THE RANDOM VARIABLE AND PROBABILITY DISTRIBUTIONS 

The random variable is a mapping of a set of elements to a sample space by a 
function [19]. For a random variable, X, the mean and variance of the random variable are 
defined as, 

E [X] = X = Mx =f j x l P(x i ) (4.1) 

i =1 

Var[X] = 4 = E[X 2 ] - (E[X]) 2 . (4.2) 


From the above statistical equations, an important quantity, known as the coeffi¬ 
cient of variation, is defined as, 


cr v 


Mx 


(4.3) 


The coefficient of variation is a nonnalized measure of the degree of variability of the 
random variable. 

In the field of queuing analysis, there are several probability distributions which 
are important. For the purpose of this study, the Poisson and exponential distributions 
will be discussed here [20]. 

Consider a discrete random variable, X, with an exponential distribution and char¬ 
acterized by the parameter ju > 0, the mean and variance are given by, respectively, 


E[X] = i 


(4.4) 
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Var[X] = -Xr. 
M 


(4.5) 


The exponential distribution is often used to model the interarrival times between 
data packets, or the service time of the data packets. Notice that the coefficient of varia¬ 
tion is equal to 1, which is a special case of the exponential distribution. 

Consider a discrete random variable, Y, which is Poisson distributed and charac¬ 
terized by the parameter X > 0, the mean and variance, respectively, 


E [Y] = X 

(4.6) 

Var[7] = X. 

(4.7) 


The Poisson distribution is important because the arrival rate of data packets is 
usually assumed to be Poisson distributed which forms the basis of developing the queu¬ 
ing theory equations. In a Poisson process, the probability of a packet arriving within an 
interval is independent of the arrival of the previous or next packet. If we model arrival 
process as Poisson, the following equations apply. 


Pr {k items arrive in time interval T} = 


m k -zt 

- e 

k\ 


(4.8) 


E{number of items arriving in time interval T\ = XT (4.9) 

Mean arrival rate (items per unit time) = X . (4.10) 

Poisson arrivals are also considered random arrivals as the probability of an item 
arriving within a small interval is proportional to the interval length and independent of 
the time elapsed since the arrival of last item. 

The Poisson process is also related to the exponential distribution. By considering 
interarrival times of T a , the following relationships are defined, 

Pr[T a < t\ = \-e~ lt (4.11) 


eki 4 

Hence, the arrival rate is the inverse of the mean interarrival time. 


(4.12) 
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C. QUEUING THEORY EQUATIONS 

Most process models are described by the Kendall’s notation [21], X/Y/N, where X 
refers to the interarrival time distribution, Y the service time distribution, and N the num¬ 
ber of server in the system. In this study, the M/M/1 model is assumed. M/M/1 is the 
model notation for a single-server with Poisson arrivals or exponential inter-arrival times, 
and exponential service times. From Equation (4.18), the arrival rate is given by, 

A = — l — = ---. (4.13) 

E [T a ] Mean Interarrival Times 

As the mean service time is related to the mean packet length and link rate, the 
mean service time is defined as [6] 

_ Mean Packet Length (bytes) x 8 
Link rate (kbits/s) 

Consequently, combining Equations (4.20) and (4.21) gives the utilization of the 

link 

p = AT s . (4.15) 

D. SELF-SIMILARITY IN COMPUTER NETWORKS 

Self-similarity is a phenomenon described for a particular process which appears 
the same when viewed at different magnification of time scales. Such processes have 
characteristics which are very different from conventional telephone traffic, which is usu¬ 
ally modeled as Poisson process. The paper by Leland et al. [8] demonstrated that 
Ethernet traffic is actually self-similar and that a Poisson process used to describe 
Ethernet traffic may not be a sufficient model. 

Self-similar processes tend to exhibit persistence in clustering which suggests that 
clustering occurs at different time scales [20] and burstiness of traffic would occur over 
long periods. This is in contrast with the Poisson process where clustering usually occurs 
in the shorter term and smoothes out over the long term. This would suggest that a Pois- 
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son arrival will flatten out over the long term. Thus buffers of data would build up shortly 
and be cleared over time. For the self-similar process, this is not the case as burstiness 
tends to prolong over long periods of time. 

The concept of self-similarity is often associated with long-range dependence 
(LRD) [6], Long-range dependence signifies the persistence of self-similar processes 
which exhibit clustering and bursty characteristics at all time scales. 

1. Modeling Self-Similarity, Long-Range Dependence and Heavy-Tailed 
Distributions 

In order to estimate the self-similar nature of the data traffic, the Hurst parameter 
[20] is used. It is a measure of the persistent nature of the self-similarity phenomenon and 
a measure of the long-range dependence of the process. A value of H = 0.5 represents an 
absence of long-range dependence and is usually associated with Poisson processes. Val¬ 
ues of H closer to 1 indicate a greater degree of persistence. 

There are several approaches in which the Hurst parameter is estimated, such as 
the “R/S plots” [5], In this study, the “Variance-Time Plot” method will be used [20]. The 
process x is said to be self-similar if the aggregated time series x (m) obeys the following, 

VarO (m} ) ~ Va y (4.16) 

m 

where the self-similarity Hurst parameter is given by, 

H = 1-^. (4.17) 

Taking the log of both sides, Equation (4.16) can be written as, 

log[Var(x ( "' ) )] ~ log[Var(x)]-/?log (m ). (4.18) 

Thus, by plotting log[Var(x r "' ; )] against log(m), the result would be a straight line of slope 
~P . Subsequently, the Hurst parameter can be deduced from Equation (4.18). 

A self-similar process is often referred to as possessing long-range dependence 
(LRD). LRD refers to processes which have autocovariance that decay very slowly or 
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there exist finite samples at larger values of the distribution. LRD has the following prop¬ 
erty [20], 

C{k)~\k\ P as & oo, 0 </?< 1, (4.19) 

where C(k) denotes the autocovariance function for the stationary process and k the ag¬ 
gregate time series for k > 0. 

Note that if /? is between 0 and 1, this means that//is between 0.5 to 1. Thus 
processes which exhibit LRD are also self-similar. Although larger f) would lead to 
lower//, i.e., less self-similar, in this study, the terms self-similarity and LRD are used 
interchangeably. 

A process is considered to possess a “heavy-tailed” distribution if large values of 
the random variable exist with non-zero probabilities [6]. 


2. Performance Implications, Norros Model 

Proposed by Norros [22], for a given self-similar process of Hurst parameter H, 
the buffer requirement q is related to the utilization p given by, 


^, 1 / 2(1 -H) 


(4.20) 


Using this equation, the utilization graph (q versus p ) could be plotted to assess 
whether the buffer requirements would escalate at lower utilization rates due to high de¬ 
gree of long-range dependence (//closer to 1). This analysis will be useful in estimating 
the buffer required for a particular network at the desired utilization rate or vice versa. 


E. SUMMARY 

This chapter has presented the probability theory and the self-similarity concepts 
which are essential tools required in analyzing data traffic. In the next chapter, the traffic 
analysis of the CTM traffic are analyzed and, using the concepts presented in this chapter, 
the statistical analysis is detailed. 
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V. TRAFFIC ANALYSIS, PERFORMANCE MODELING AND 

ESTIMATION 


A. CHAPTER OVERVIEW 

This chapter presents the traffic analysis of the collected SONET management 
traffic. A close analysis is perfonned on the data packets collected from Ethereal which is 
followed by statistical analysis to determine the mean interarrival times and packet size 
of the different types of management traffic. Next the computations of the Hurst parame¬ 
ters are presented which leads to the estimation of link utilization for the different types 
of management traffic. Finally, comparisons with the previous research are presented. 


B. TRAFFIC ANALYSIS OF SONET MANAGEMENT TRAFFIC 

The SONET management traffic was collected using Ethereal during the ten-day 
period from 28 January to 6 February 2005. The duration of the ten-day data collection 
period was chosen to make it consistent with the prior research [11, 12]. Over the ten-day 
collection period, the total number of packets collected and the respective breakdown of 
the types of SONET management traffic are presented in Table 5. 



This Study 

Previous work 


Case 1 

Case 2 

Case 3 

Types of traffic 

Data collected 

Data collected 

Data collected 


from 28 Janu¬ 

from Ng 

from Lim 


ary to 6 Febru¬ 

(From Ref. 

(From Ref. 


ary 2005 

[121.) 

HU.) 

CTM Socks 

86730 

94916 

203278 

CTM SNMPv2 

3714 

4332 

7364 

CTM Socks and SNMPv2 

90444 

99248 

210642 

CTM Ethernet 

238659 

206694 

471103 

Others 

212904 

98138 

193333 

Total (CTM Ethernet + Others 

452563 

304832 

664436 


Table 5. Breakdown of the number of data packets collected for the CTM traffic 

and comparison with previous works 


From the data packets collected, only the Socks, SNMP and the related TCP 
packets related were used in this analysis. There were plenty of packets from the General 
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Inter-Orb Protocol (GIOP) communications which is not relevant to this study as they 
were routine database updates to-and-from the CTM server with the NEs, although they 
were part of the SONET management traffic. The Socks traffic was due to the NEs updat¬ 
ing their status information with the CTM server, while the SNMPv2 traffic was due to 
the CTM server initiating “GetBulk” commands from the NEs. The total management 
traffic of Socks, SNMPv2 and the related TCP packets are collectively termed as “CTM 
Ethernet.” 

For the purpose of this traffic analysis discussion, Case 1 is used for this study for 
data collected under loading with network disruption conditions. Case 2 is used for data 
collected under loading, as referenced from [12]. Case 3 is referring to data collected un¬ 
der no-load conditions [11]. 

Looking at the number of packets collected from Case 1, considering that disrup¬ 
tion was applied to the SONET network, it was found that the number of Socks and 
SNMPv2 were about 10% less than that collected when there was no disruption. Al¬ 
though the SONET network was continuously loaded by the SmartBits traffic generator, 
the management traffic appeared to drop by some extent. This drop is due to the network 
outages when the ONS15454 was turned off. It was noted that, on the average, the 
ONS15454 took about 7 minutes to synchronize the optical circuits after it is switched 
on. By taking into consideration of the outage time duration, the network availability was 
computed to be about 97.16%. Thus the network outage of 2.84% has caused the Socks 
and SNMPv2 packets to drop by 10%. 

When considering the overall management traffic, the total amount of Ethernet 
packets was higher compared to Case 2. This could be due to CTM issuing more health 
status requests to the NEs that were offline but less Socks packets as the NEs were down. 
The increase in TCP communications was about 20% as noted from the table. Another 
possibility could be due to online NEs which are communicating more often with the 
CTM server when one of the NEs is down. 

Comparing Case 1 with Case 3, the management traffic was significantly lower 
by more than 50%. The consequence of loading the network with applied disruption has 
reduced the number Socks and SNMPv2 traffic drastically. This is an interesting phe- 
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nomenon as the main cause is due to the disruption. This is expected because there would 
be less Socks and SNMPv2 packets generated when the NEs were down. 


C. STATISTICAL ANALYSIS AND COMPARISONS WITH PRIOR WORK 

From the data collected, the random variables of interest are interarrival times and 
the packet sizes. As the total number of packets is very large, manual calculation of the 
statistics would be very tedious. Furthermore, in order to extract the Hurst parameter, the 
variances have to be computed for different aggregated time series (10, 32, 100, 320 and 
1000 seconds). To simplify the process, two Mathcad script fdes were used to carry out 
the required operations. Both of these script files were developed by Lieutenant James 
Young from the EC4850 (Summer 2003) class. The first script file computes the mean 
and variances of interarrival times and packet sizes of the data collected. In addition, it 
also computes the variances for several aggregated time series data. The second script file 
computes the histogram distribution of the interarrival times and packet lengths and out¬ 
puts to a Microsoft Excel file, which is then plotted to give the distribution of the data 
traffic. 


1. Interarrival Times Distribution Graphs 

Using the Mathcad script, the histogram data was generated, exported to Excel 
and plotted. Figures 15, 16, 17 and 18 shows the interarrival times distributions for the 
loading/disruption and loading/no disruption cases. 


Interamval times distribution for Socks Traffic (Loading/Disruption) 


Inter-arrival Time Distribution for Socks Traffic 




Time (seconds) 


Figure 14. Distribution of Socks traffic interarrival times, loading/disruption (left), 

loading (Right, from Ref. [12].) 
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Inter-arrival Time Distribution for SNMP Traffic 



Figure 15. Distribution of SNMPv2 traffic interarrival times, 

loading/disruption (left), loading (Right, from Ref. [12].) 


Interarrival times distribution for Socks/SNMPv2 Traffic 
(Loading/Dismption) 


CN — ro 


Interarrival times (s) 


Inter-arrival Time Distribution for Socks and SNMP Traffic 



OO <N t-~ 


Time (seconds) 


Figure 16. Distribution of combined Socks/SNMPv2 traffic interarrival times, 
loading/disruption (left), loading (Right, from Ref. [12].) 


Inter-arrival times distribution for Ethernet Traffic (Loading/Disruption) 



Inter-arrival times (s) 


Inter-arrival Time Distribution for Ethernet Traffic 



Time (seconds) 


Figure 17. Distribution of Ethernet traffic interarrival times, 

loading/disruption (left), loading (Right, from Ref. [12].) 


Figure 14 shows that the Socks traffic exhibits a “heavy-tailed” distribution. It is 
observed that Socks traffic with loading and disruption decays slightly faster than the 

loading case for small values of interarrival times. This suggests that the arrival rate is 
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slightly smaller in the case when the network is loaded and disrupted. Although the load¬ 
ing/disruption case decays slightly faster, it is still “heavy-tailed.” This suggests that the 
Socks traffic has prolonged burstiness. For the no disruption case, though, the tail is 
slightly larger compared to the loading/disruption case. 

In Figure 15, the loading/disruption SNMPv2 traffic exhibit a slight degree of 
“heavy-tailed” distribution as opposed to the loading/no-loading case which resembles an 
exponential distribution. Close examination on the loading/disruption case appears to de¬ 
cay faster than that of the loading/no disruption case for small interarrival times. 

In Figure 16, similar observations were made. For the combined Socks and 
SNMPv2 traffic, it is observed that the Socks distribution dominates as depicted by the 
similarity between Figures 14 and 16 for the loading/disruption case. Furthermore, it is 
observed that the loading/disruption case has a slightly smaller tail compared to the load- 
ing/no-disruption case and decays slightly faster for small interarrival times. 

Similar observations are made for the CTM Ethernet traffic as depicted in Figure 
17. In general, the loading/disruption interarrival time distribution decays faster but has a 
larger tail compared to the no-disruption case. 


2. Interarrival Times Statistics 

Using the Mathcad script, the statistics of mean, variance and coefficient of varia¬ 
tion, using Equation (4.3) are computed. Tables 6, 7 and 8 tabulate the values for the 
mean, variance and coefficient of variation, respectively. The respective values are com¬ 
pared with those of loading, loading without disruption and no loading. 


Mean, E [T a ] (s) 

Loading/ 

Disruption 

Loading (From 
Ref. [12].) 

No loading 
(From Ref. [11].) 

CTM Socks 

10.858 

8.2 

4.553 

CTM SNMPv2 

253.581 

179.533 

120.043 

CTM Socks and SNMPv2 

10.413 

7.842 

4.394 

CTM Ethernet 

3.93 

3.213 

1.965 


Table 6. Comparison of means of interarrival times 
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Variance (s 2 ) 

Loading/ 

Disruption 

Loading (From 
Ref. [121.) 

No loading 
(From Ref. [111.) 

CTM Socks 

2356 

1630 

772 

CTM SNMPv2 

l.lOxlO 7 

4.54xl0 6 

6.27xl0 5 

CTM Socks and SNMPv2 

2242 

1560 

746 

CTM Ethernet 

821 

543 

324 


Table 7. Comparison of variances of interarrival times 



Loading/ 

Disruption 

Loading (From 
Ref. [12].) 

No loading 
(From Ref. [11].) 

CTM Socks 

4.471 

4.927 

6.103 

CTM SNMPv2 

13.062 

11.863 

6.597 

CTM Socks and SNMPv2 

4.547 

5.041 

6.215 

CTM Ethernet 

7.293 

7.249 

9.159 


Table 8. Comparison of coefficient of variation of interarrival times 


From Table 6, it is observed that the overall means for the loading/disruption case 
are higher compared to those of the loading and no-loading cases. This is expected as the 
average duration of the network outages adds to the mean interarrival times of the statis¬ 
tics. For Table 7, the variances obtained from loading/disruption case are higher in gen¬ 
eral. This is expected as the network outages introduce some degree of irregularities into 
the interarrival times. In Table 8, it is observed that the loading/disruption coefficients of 
variations of the different types of traffic are close to those of loading. This might suggest 
that the degree of variability does not change significantly when the network was subject 
to disruption. In contrast, when comparing the loading/disruption case to the no-loading 
case, the higher value for SNMPv2 suggests that the disruptive network has increased the 
variability of SNMPv2 traffic significantly. 


3. Arrival Rates 

After computing the mean interarrival times, the arrival rates for the respective 
traffic are computed using Equation (4.13). Table 8 shows the arrival rate comparisons 
for the current work (loading/disruption case) with previous research. 

It is observed from Table 8 that all arrival rates of loading/disruption case are all 


lower than those of loading and no-loading cases. This is expected as network outages 
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caused a reduction of traffic between the server and the NE that was down. As for the 
CTM Ethernet traffic, the drop in arrival rate is fairly small, suggesting that the network 
outage causes little disruption to the CTM Ethernet traffic. 


Arrival rates, X (s' 1 ) 

Loading/ 

Disruption 

Loading (From 
Ref. [12].) 

No loading 
(From Ref. [11].) 

CTM Socks 

0.092 

0.122 

0.220 

CTM SNMPv2 

0.00394 

0.00557 

0.008 

CTM Socks and SNMPv2 

0.096 

0.128 

0.228 

CTM Ethernet 

0.254 

0.311 

0.509 


Table 9. Comparison of arrival rates 


4. Packet Size Distribution 

Using the Mathcad script, the histogram data is generated, exported to Excel and 
plotted. Figures 18, 19, 20 and 21 shows the packet size distributions for the load¬ 
ing/disruption, loading and no-disruption cases. 



Figure 18. Distribution of Socks traffic packet sizes, loading/disruption (left), 

loading (Right, from Ref. [12].) 


Racket size distribution for SNMPv2 Traffic (Loading/Disruption) 



Packet Size Distribution for SNMP Traffic 


.2 1000 
| 

g> 100 
% 10 


Packet Size (bytes) 


Figure 19. Distribution of SNMPv2 traffic packet sizes, loading/disruption (left), 

loading (Right, from Ref. [12].) 
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Packet size distribution for Socks/SNMPv2 Traffic (Loading/Disiuption) 
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Figure 20. Distribution of Socks/SNMPv2 traffic packet sizes, 

loading/disruption (left), loading (Right, from Ref. [12].) 



Figure 21. Distribution of Ethernet traffic packet sizes, loading/disruption (left), 

loading (Right, from Ref. [12].) 


From Figure 18, it is observed that both loading/disruption and loading cases have 
similar distribution of Socks data packets. The loading/disruption case appears to have 
more packets in the region of 100-200 bytes. In Figure 19 of the SNMPv2 packet size 
distribution, it is observed that the distribution exhibits a heavy-tail as there exists finite 
samples at higher values. The loading/disruption case has higher number of packets in the 
regions of 260, 344 and 800 bytes. 

In Figure 20 for the combined Socks and SNMPv2 traffic, it is observed that the 
loading/disruption case has a slightly heavier tailed compared to loading/no-disruption 
case. For Figure 21, the same observations hold for the CTM Ethernet traffic. 


5. Packet Size Statistics 

The mean, variance and coefficient of variation are computed and shown in Ta¬ 
bles 10, 11 and 12, respectively. 
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Mean (bytes) 

Loading/ 

Disruption 

Loading (From 
Ref. [121.) 

No loading 
(From Ref. [111.) 

CTM Socks 

143 

172 

145 

CTM SNMPv2 

376 

441 

455 

CTM Socks and SNMPv2 

152 

184 

156 

CTM Ethernet 

116 

125 

103 


Table 10. Comparison of means of packet size 


Variance (bytes 2 ) 

Loading/ 

Disruption 

Loading (From 
Ref. [121.) 

No loading 
(From Ref. [111.) 

CTM Socks 

27690 

35800 

21537 

CTM SNMPv2 

62320 

61200 

2628 

CTM Socks and SNMPv2 

31260 

40000 

42122 

CTM Ethernet 

23370 

27900 

13118 


Table 11. Comparison of variances of packet size 



Loading/ 

Disruption 

Loading (From 
Ref. [12].) 

No loading 
(From Ref. [11].) 

CTM Socks 

1.166 

1.101 

1.09 

CTM SNMPv2 

0.664 

0.561 

1.012 

CTM Socks and SNMPv2 

1.161 

1.089 

0.113 

CTM Ethernet 

1.321 

1.334 

0.996 


Table 12. Comparison of coefficient of variances of packet size 


From Table 10, it is observed that the mean packet size for the loading/disruption 
case is lower compared to both loading and no-loading cases except for the CTM 
Ethernet traffic. The mean packet size for loading/disruption case is lower than that of 
loading but higher than no-loading case. This phenomenon could be due to smaller pack¬ 
ets been transacted between the server and the NEs or it could be as a result of more 
packets for the loading/disruption case compared to the loading case. As for Table 11, the 
loading/disruption case’s variances are generally lower except for the SNMPv2 traffic 
which is close to that of the loading case. 

For Table 10, it is observed that the coefficient of variances for the load¬ 
ing/disruption case is close to that of the loading case. This suggests that the network dis¬ 
ruption did not alter the packet size distribution very much. But, when compared to the 
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no-loading case, there is a significant difference for the SNMPv2 traffic as it is less than 
1, although higher than the loading case’s. 


6. Service Times 

From the mean packet size, the mean service times are computed using Equation 
(4.14). The values are shown in Table 13, along with the results from previous research. 
Note that during the computation, the link rates for Socks and SNMPv2 are 192 kbps, for 
the SDCC link, while that for the CTM Ethernet traffic is 100 Mbps. 


Mean Service Times, T s 
(ms) 

Loading/ 

Disruption 

Loading (From 
Ref. [12].) 

No loading 
(From Ref. [11].) 

CTM Socks 

5.944 

7.161 

6.044 

CTM SNMPv2 

15.661 

18.382 

18.967 

CTM Socks and SNMPv2 

6.343 

7.651 

6.496 

CTM Ethernet 

9.257ps 

10.021ps 

8.214ps 


Table 13. Comparison of Service Times 


It is of interest to note that the service times for the Socks and SNMPv2 traffic are 
lower compared to the loading and no-loading cases. This is due to fewer packets sent in 
the network when one or two of the NEs were down. The CTM Ethernet traffic service 
time is lower than the loading case but higher than the no-loading case. This is because 
the CTM server takes slightly longer to process the packets due to the larger packet size 
compared to the no-loading case, while it takes a slightly shorter time to process due to 
the smaller packet size compared to the loading case. 


7. Link Utilization 

Using Equation (4.15), the link utilization for 4 NEs is computed as shown in Ta¬ 
ble 14. It is then extrapolated to detennine the utilization for 2500 NEs presented in Table 
15. 
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Loading/ 

Disruption 

Loading (From 
Ref. [121.) 

No loading 
(From Ref. [111.) 

CTM Socks 

5.475x1 O' 4 

8.736xl0' 4 

1.330xl0' 3 

CTM SNMPv2 

6.176xl0' 5 

1.024x1 O' 4 

1.580xl0' 4 

CTM Socks and SNMPv2 

6.092xl0' 4 

9.793xl0' 4 

1.480xl0' 3 

CTM Ethernet 

2.356xl0' 6 

3.1 17 x 10" 6 

4.180xl0' 6 


Table 14. Comparison of link utilization for 4 NEs 



Loading/ 

Disruption 

Loading (From 
Ref. [121.) 

No loading 
(From Ref. [111.) 

CTM Socks 

0.342 

0.546 

0.830 

CTM SNMPv2 

0.039 

0.064 

0.099 

CTM Socks and SNMPv2 

0.381 

0.612 

0.926 

CTM Ethernet 

1.472x1 O' 3 

1.948xl0' 3 

2.620xl0' 3 


Table 15. Comparison of link utilization for 2500 NEs 


From the results shown in Table 15, it is observed that the effective network utili¬ 
zation for the combined CTM Socks and SNMPv2 traffic is lower compared to loading 
and no-loading cases. Intuitively, although the network utilization were expected to be 
lower due to disruption, the statistical analysis presented has shown that the results match 
the initial guess. Therefore, the net effect of loading coupled with network disruption has 
decreased the network utilization further due to a combination of lower arrival rate and 
lower service time (although lower than the loading case but higher than the no-loading 
case). 


8. Log-Variance Versus Aggregated Interarrival Time and Packet Size 
Series Plots 

Using the Mathcad script files, the variances for respective aggregated time series 
are generated and exported to Excel worksheets. The variance versus aggregate interarri¬ 
val time and packet size series plots are plotted for the various CTM data traffic. Figures 
22 to 29 show the variance plots for the various CTM data traffic. Note that the approxi¬ 
mate variances values for the loading case are plotted along the same respective aggre¬ 
gates. The straight line is fitted to the loading/disruption plots in order to extract the gra¬ 
dient for the computation of the Hurst parameters. 
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From Figure 22, for the loading/disruption case of Socks traffic, it is observed that 
the log-variance values at higher aggregates of 1.5 to 3 (corresponding to 32 to 1000) are 
higher by about 0.5. Further, the variance is higher at smaller aggregated time-series val¬ 
ues such that the curve has more of an exponential decay than a linear decay. This im¬ 
plies that there exists a higher degree of long-range dependence over the long term than 
over the short term. 


Variance Interarrival Time Plot for Socks Traffic 
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Figure 22. Graph of Variance-time plots for Socks traffic 


From Figure 23, for the loading/disruption case of SNMPv2 traffic, it is observed 
that the log-variance values at aggregate values above 1.5 are higher compared to the 
loading case. At an aggregate value of 3, the difference is almost 1 which corresponds to 
a factor of 10. 
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Variance Interarrival Time Plot for SNMPv2 Traffic 



Figure 23. Graph of Variance-time plots for SNMPv2 traffic 


From Figure 24, for the loading/disruption case of combined Socks/SNMPv2 traf¬ 
fic, it is observed that the log-variance values are higher compared to that of the loading 
case. Again, the curve exhibits more of an exponential decay implying that there may be 
higher long-tenn dependence over longer intervals. 


Variance Interarrival Time Plot for SNMPv2 and Socks Traffic 
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Figure 24. Graph of Variance-time plots for combined Socks/SNMPv2 traffic 


From Figure 25, for the loading/disruption case of the CTM Ethernet traffic, it is 
observed that the log-variance value at aggregate 1 is higher by about 1 (or factor of 10). 
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Variance Interarrival Time Plot for Ethernet Traffic 



Figure 25. Graph of Variance-time plots for Ethernet traffic 


From Figures 26 to 29, for the loading/disruption case of packet size, the log- 
variance values are very close to that of the loading case. This suggests that the packet 
size distribution varies slightly due to disruption. In Figure 29, it is observed that the log- 
variances values for the loading/disruption case are lower compared to the loading case. 
At a log aggregate time series of 1, the value is higher by about 0.7 (or a factor of 5). 
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Variance Packet Size Plot for SOCKS Traffic 
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Figure 26. Graph of Variance-packet size plots for Socks traffic 
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Variance Packet Sze Plot for SNMPv2 Traffic 



Figure 27. Graph of Variance-packet size plots for SNMPv2 traffic 


Variance Packet Size Plot for SNMPv2 and SOCKS Traffic 



Figure 28. Graph of Variance-packet size plots for combined 

Socks/SNMPv2 traffic 
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\ a nance Packet Size Plot for Ethernet Traffic 
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Figure 29. Graph of Variance-packet size plots for Ethernet traffic 

9. Self-Similarity Analysis and Hurst Parameter 

From Figures 22 to 29, the respective gradients of the straight-line fits were ex¬ 
tracted for computation of Hurst parameters. Tables 16 and 17 present the Hurst parame¬ 
ter computed using Equation (4.17) after extracting the slope (-/? ) from the straight-line 
fit. 
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Interarrival Times 

Loading/ 

Disruption 

Loading (From 
Ref. [12].) 

No loading 
(From Ref. [11].) 

CTM Socks 

0.7224 

0.8073 

0.5050 

CTM SNMPv2 

0.4730 

0.8314 

0.7024 

CTM Socks and SNMPv2 

0.7338 

0.8124 

0.5108 

CTM Ethernet 

0.5764 

0.7334 

0.6838 


Table 16. Comparison of Hurst parameters of interarrival times 


Packet Size 

Loading/ 

Disruption 

Loading (From 
Ref. [12].) 

No loading 
(From Ref. [11].) 

CTM Socks 

0.7293 

0.8256 

0.5567 

CTM SNMPv2 

0.4713 

0.7349 

0.9066 

CTM Socks and SNMPv2 

0.7440 

0.8248 

0.6227 

CTM Ethernet 

0.7190 

0.8430 

0.8025 


Table 17. Comparison of Hurst parameters of packet size 
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On the Hurst parameters for the interarrival times, the loading/disruption-case val¬ 
ues are lower compared to loading-case values. This suggests that the management traffic 
has become less self-similar which is due to the network disruption. As noted above, 
there is some short-term bias in these values which may be closer to the non-disruption 
case over the long term. The loading/disruption-case Socks and the combined 
Socks/SNMPv2 traffic are more self-similar compared to the no-loading case, while the 
loading/disruption-case CTM Ethernet traffic is less self-similar compared to no-loading 
case. This is consistent with the earlier analysis of the interarrival times distribution 
graphs as the higher degree of the long-range dependence implies lower f) , which means 
a higher H value by Equation (4.17). It is of interest to note that SNMPv2 has a Hurst 
value less than 0.5, which suggests that the SNMPv2 traffic is not self-similar. 

Similar observations are made for the packet sizes. In general, the load¬ 
ing/disruption-case packet sizes deceases in its self-similarity compared to the loading 
case, while the SNMPv2 packet size is not self-similar. The loading/disruption-case 
Socks and the combined Socks/SNMPv2 packet sizes are more self-similar compared to 
no loading case, but the loading/disruption case Ethernet traffic is slightly less self¬ 
similar compared to no-loading case. 

10. Effects of Self-Similarity on the Queue Size 

To understand the effect of self-similarity on the queue size, the graphs for q ver¬ 
sus p are plotted for different Hurst parameters using Equation (4.20) based on Norros’ 
model. Figures 30 and 31 show the graphs for q = 10 and 100, respectively. 

From Figure 30, it is observed that moving from a utilization rate of p = 0.38 to 
0.67, the queue size increases by 10 fold. In Figure 31, going from p = 0.67 to 0.83 
causes the queue size to increase further to 100. This is highly undesirable as more pack¬ 
ets are building up at the queue of the CTM server. Too much queuing is undesirable. 
Hence, for safe operation, the number of NEs should not exceed 2495. Coincidentally, 
this figure corresponds to the specification that the CTM server can manage a maximum 
of 2500 NEs. 
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Graph of Queue Size vs Utilization for q = 1 to 10 
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Figure 30. Graph of Queue Size vs Utilization for q = 1 to 10 
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Graph of Queue Size vs Utilization for q = 1 to 100 
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Figure 31. Graph of Queue Size vs Utilization for q = 1 to 100 
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11. Maximum Number of Manageable NEs 

In the computation of the number of manageable NEs, only the CTM’s combined 
Socks and SNMPv2 traffic are of interest as they occupy the 192-kbps SDCC link. It is 
noted that when p = 0.38, the queue sizes of all the data traffic are less than 1. In order 
to maintain a queue size of less than 1 at the CTM server, the utilization must not exceed 
0.38; therefore the corresponding number of NEs for the respective CTM server traffic 
are computed as shown in Table 18. 



Loading/ 

Disruption 

Loading (From 
Ref. [12].) 

No loading 
(From Ref. [11]) 

CTM Socks 

2776 

1739 

1142 

CTM SNMPv2 

24611 

14843 

9620 

CTM Socks and SNMPv2 

2495 

1552 

1027 


Table 18. Comparison of number of NEs for p =0.38 


It is observed that the number of manageable NEs based on the CTM’s combined 
Socks and SNMPv2 traffic is 2495 which is a 61% increase from the loading case. It 
should be noted, however, that this is a liberal estimate due to the bias of short-tenn ag¬ 
gregated time series on the Hurst parameter calculation. Prudent operation would suggest 
operating with fewer NEs on the network. 


D. SUMMARY 

In this chapter, the traffic and statistical analysis of the CTM management data 
packets collected has been presented. The statistics of the interarrival times and packet 
sizes were also computed and distribution graphs plotted. The log-variance vs. aggre¬ 
gated interarrival times and packet sizes graphs were plotted which allows the gradients 
of the straight-line fit to be extracted and the Hurst parameter computed. Finally, the ef¬ 
fects of utilization on the queue size were discussed with the help of queue size plots. 
From the statistical analysis, much understanding was gained on the nature of the CTM 
traffic under loading and disruption conditions. 

The next chapter concludes the analysis and the findings. Future possible research 
areas are also discussed. 
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VI. CONCLUSION AND FUTURE RESEARCH AREAS 


A. CHAPTER OVERVIEW 

This chapter summarizes the traffic and statistical analysis of the SONET Net¬ 
work Management System CTM server data traffic and observations. From the findings 
of the analysis, several future research areas are proposed. 


B. CONCLUSION 

The analysis of the CTM management traffic has shown that the Socks and 
SNMPv2 traffic decreases when the SONET network is fully loaded and disruptive 
power failures are applied. Further, the total number of CTM Ethernet packets of the 
SONET management system is about 20% higher compared to the amount of data pack¬ 
ets collected when the SONET network was fully loaded without any disruption. This is 
an interesting phenomenon as the server has initiated more TCP transactions but less 
Socks and SNMPv2 packets in the event of disruption within the SONET network. The 
increase in TCP packets is probably due to the CTM server polling for the health status of 
the NEs which are down. It may also be associated with TCP retransmissions due to time¬ 
out conditions. Nevertheless, the total Ethernet traffic is observed to be about 50% less 
compared to the case when the SONET network is not loaded. Hence, it is concluded that 
the nature of the CTM server traffic is such that more Ethernet traffic is generated when 
the NE is down, while less Socks and SNMPv2 packets are observed when the NE is 
down. 

Further analysis of the data packets collected using statistical methods reveal 
more interesting facts about the CTM management traffic. The statistical means of the in¬ 
terarrival times of CTM’s different management traffic (Socks, SNMPv2 and Ethernet), 
were all higher compared to the case when the network was not disrupted. The higher 
means are due to the time outages during which the offline NE is not communicating 
with the CTM server. The evaluation of the coefficient of variation for the interarrival 
times revealed that the CTM’s different management traffic vary only slightly when a 
SONET network is disrupted, even though the graphs of the interarrival time distribution 
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depicted that the loading/disruption exhibit slightly faster exponential decays. This, in 
turn, suggests that the arrival rate for the loading/disruption case is lower which means 
that mean interarrival times are higher. This is consistent with the higher mean interarri¬ 
val times computed. 

Although the SONET network was fully loaded and disruption injected into the 
network, the packet length distributions of the CTM management traffic (includes Socks, 
SNMPv2 and Ethernet) appeared to vary very little as depicted by the graphs. Again, this 
is consistent with the close coefficient of variation values between the loading/disruption 
and loading case. Nevertheless, the mean packet sizes of the CTM Ethernet traffic was 
lower for the loading/disruption case which is due to more TCP packets generated by the 
CTM server. Interesting enough, the Socks and SNMPv2 traffic mean packet sizes were 
lower even though there is less Socks and SNMPv2 traffic. Thus, it is concluded that the 
TCP packets generated by CTM server have a more dominant effect. 

The self-similarity analysis revealed a more interesting nature about the CTM 
management traffic. The Socks traffic Hurst value of 0.7224 was found to be lower than 
the loading case of 0.8073, but higher than no-load case of 0.505. There is a bias due to 
the short-term aggregated time series which means that these estimates should be liber¬ 
ally considered. The lower Hurst value suggests that disruption with a loaded network has 
reduced the degree of self-similarity while still high enough due to network loading com¬ 
pared to no-load case. This suggests that the less bursty nature of the Socks traffic is a re¬ 
sult of the offline NE(s) which is/are not sending Socks packets to the CTM server. 

On the self-similarity analysis of the loading/disruption SNMPv2 traffic, the 
Hurst value of 0.4730 suggests the absence of self-similarity as it is less than 0.5. This is 
consistent as a Hurst value of 0.5 or less indicates the absence of long-range dependence 
which is apparent in the SNMPv2 interarrival time distribution graph. This also suggests 
that the SNMPv2 becomes less bursty over prolonged operation in an environment that is 
affected by severe network outages. This would mean that SNMPv2 operation could 
break down in the event of network outages which would result in CTM server not up- 


50 



dated with the latest management information of the NEs. Thus it is concluded that the 
CTM SNMPv2 traffic does not operate well in a network environment with severe net¬ 
work outages. 

The combined Socks and SNMPv2 traffic Hurst value was found to be lower than 
the loading case of 0.8124, but higher than no-load case of 0.5108. This is similar to the 
Socks traffic case which suggests that the Socks traffic has a more dominant self¬ 
similarity nature than SNMPv2. The Ethernet traffic’s Hurst value of 0.5764 is less than 
both the loading and no-load values of 0.7334 and 0.6838, respectively. This indicates 
that the Ethernet traffic has become less self-similar due to network disruption. Similar 
observations were made on the packet-size Hurst values for the CTM management traf¬ 
fic. 

The loading/disruption link utilization was computed as 0.381 for 2500 NEs. This 
value is lower compared to both loading (p = 0.612) and no-loading (p = 0.926) cases, 
even though the total Ethernet packets collected for the loading/disruption case is more 
than the loading case while less than that of no-load case. Thus, the total number of pack¬ 
ets collected does not relate to the degree of link utilization but, rather, statistical methods 
have to be employed to compute the resultant utilization. The lower link utilization sug¬ 
gests that SDCC link has been less utilized due to the offline NE. 

The effect of link utilization on queue size was investigated so as to detennine the 
amount of queuing buffer required at different utilizations. It was observed that increas¬ 
ing the utilization from 0.38 to 0.67 (corresponding to 4400 NEs), for the combined 
Socks and SNMPv2 traffic, the queue size would increase from 1 to 10. The queue will 
again be increased to 100 if the link utilization is further increased from 0.67 to 0.83 as 
we increase the number of NEs to 5450. Therefore, even though the SDCC link would 
achieve link utilization of 0.83 for 5450 NEs, the queue size would be 100 which is unde¬ 
sirable. Therefore, for safe operation, while adhering to a queue size of 1 (p = 0.38) at the 
CTM server, the number of manageable NEs was computed as 2495 under load¬ 
ing/disruption conditions. This value is close to the CISCO specification of 2500 man¬ 
ageable NEs for the CTM server, although it should be considered aggressive as there is 
some short-term bias affecting the calculation. 
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The effects of power loading coupled with power disruptions have been studied in 
this thesis and the work will be useful for high-speed computer networks administrators. 
The results and findings of this thesis will benefit the SONET network administrators by 
increasing their awareness of the limitations of SONET network management systems so 
as not to expand the network beyond 2500 NEs. They will also understand the behavior 
of SONET management traffic in a power disruption environment and that the CTM is 
able to function in the disruptive environment simulated in this thesis. Further, this re¬ 
search provides the ability to optimize the deployment of SONET optical systems, based 
on the utilization of the management traffic presented, in order to tackle network prob¬ 
lems associated with network loading and power disruptions. 


C. FUTURE RESEARCH AREAS 

The traffic and statistical analysis have allowed the nature of the CTM server traf¬ 
fic be thoroughly investigated under the condition when the SONET fiber network is 
fully loaded and disruption injected. A number of future possible research areas have 
been identified as follows. 

1. Varying the Number of Network Elements and Network Topology 

As the current work is performed on four NEs connected in a ring configuration, 
the results may possibly be different if more NEs are added. It is proposed that at least 
two NEs to be added to the current network. With two additional NEs, a total of six NEs 
would be available which allows all six of them to be connected in single ring network or 
a dual ring network. The results would be very useful for a network administrator to de¬ 
cide on which configurations optimize the CTM 4.6 management system. 

2. Performance Analysis of SONET SDCC Link Performance 

The current work has analyzed the performance of the CTM 4.6 in managing the 
Network Elements under network loading and disruptive conditions. As the analysis was 
investigated at the IP layer, the SDCC link performance was not analyzed. It would be an 
interesting research area to analyze the physical optical layer perfonnance to understand 
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what happens to the SDCC link when the network is disrupted and how the link recovers 
from the disruption. 

3. Correlation between Network Outages and Network Utilization 

This study has investigated the performance of the CTM server traffic under load¬ 
ing and disruption. As the disruption was simulated randomly, i.e., the frequency at 
which the NE is switched off and the number of NEs turned off, further investigation 
could be made to ascertain whether is there any correlation between the degree of outages 
and statistics or self-similarity nature of the CTM server management traffic. 

4. Comparing CTM 4.6 with Third-party Network Management Sys¬ 
tems 

As SONET/SDH is an open optical transport standard, there exists several net¬ 
work management systems on the market which claim to support SONET/SDH equip¬ 
ment. Purchase and evaluation of third-party SONET/SDH network management systems 
to compare the differences in performance as well as scalability is recommended. Exam¬ 
ples of third-party SONET/SDH management systems are the Navis® Optical Manage¬ 
ment System (OMS), marketed by Lucent Technologies [23], and the Alcatel 1350 Man¬ 
agement Suite [24]. 
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